What do you think about this one @treeowl? Seems like an easy merge if you're 👍 on the idea

@emilypi, I'm generally okay with exposing constructors through Internal modules, with the understanding that we are free to break anything at any time. I have my doubts about #25 itself.

#25 does seem a little wonky, I agree. I suppose we can treat it like we treat Data.ByteString.Internal where it's caveat emptor.

FWIW, I like how prettyprinter has addressed the internal modules issue:

• There's an Internal module that can export anything that people want to access. It doesn't currently export everything though, since that can prevent some optimizations. This module comes with no stability guarantees at all.
• There's also a PVP-compliant Internal.Type module that exports the main type with its constructors. This means that other library authors can use the constructors without having to maintain an upper bound on minor versions.

So how about exporting the HashMap constructors from Data.HashMap.Type[s] (or Data.HashMap.Internal.Type[s]?) with the usual PVP stability guarantees?

That would leave the path open to a possible addition of a Data.HashMap.Internal module that would give access to internal functions, but without the stability guarantees…

@emilypi, @treeowl As a way forward, how about we merge this and add a module header that clarifies that the module is excepted from the PVP?

That should leave all other options open.

@jaspervdj Are you interested in driving this to completion or can e.g. I take over?

Let's move the discussion on what should be exposed and how it should be exposed to #211.

I'll mark this PR as a draft until we have a proper plan.

Superseded by #283.